Fix Codex Fast mode accounting from current trace records - #2519
Fix Codex Fast mode accounting from current trace records#2519Anri-Lombard wants to merge 1 commit into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d0b94e5806
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| guard body.contains(#"service_tier: Some(Some("priority"))"#), | ||
| let submissionRange = body.range(of: "Submission sub=Submission {") |
There was a problem hiding this comment.
When a standard-mode user prompt itself contains service_tier: Some(Some("priority"))—for example, while debugging or pasting a trace—the serialized Submission row includes that text in op: UserInput even though its actual ThreadSettingsOverrides uses the default tier. This whole-body check therefore marks that standard turn as Fast and overstates its cost; inspect the actual thread_settings field rather than accepting the marker anywhere in the prompt-bearing row.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs real behavior proof before merge. Reviewed July 31, 2026, 7:02 PM ET / 23:02 UTC. ClawSweeper reviewWhat this changesThe PR recognizes current Codex Submission trace rows as priority usage during SQLite scans and adds parser and database regression tests. Merge readiness⛔ Blocked until real behavior proof is added - 7 items remain Keep this PR open. The requested current-trace support is not on Priority: P2 Review scores
Verification
How this fits togetherCodexBar scans local Codex trace records stored in a SQLite log cache to identify priority turns. The resulting turn metadata is joined with usage data to calculate the menu bar app’s Codex usage and cost display. flowchart LR
A[Codex trace records] --> B[SQLite log cache]
B --> C[Priority trace scanner]
C --> D[Priority turn metadata]
D --> E[Usage and cost matching]
E --> F[Menu bar usage display]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Parse the actual Do we have a high-confidence way to reproduce the issue? Yes, from source: a Submission row with the marker inside Is this the best way to solve the issue? No: recognizing Submission rows is the right boundary, but searching the whole prompt-bearing record is not safe. Restrict the detection to the serialized Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8ef86077e70a. LabelsLabel justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
clawsweeper
Bot
added
the
merge-risk: 🚨 other
1 participant
Summary
CodexBar currently misses Fast/Priority mode for current Codex/Luna sessions. Those sessions record priority usage in
Submissiontrace rows withservice_tier: Some(Some("priority")), while the scanner only recognized legacy websocket request rows.This causes current Fast mode sessions to be classified as standard-cost usage.
Changes
Submissionrows in bounded and incremental SQLite scans.Validation
swift test --filter CostUsageScannerCodexPriorityTests— 21 passedswift test --filter CostUsageScannerPriorityTests— 16 passedmake check— passed, including SwiftFormat/SwiftLint and repository gatesmake test— passed, 758 selections across 64 groupsObserved local evidence: Codex logs contain
service_tier: Some(Some("priority"))for current sessions, while the pre-fix CodexBar cache classified the same session as standard.